home *** CD-ROM | disk | FTP | other *** search
/ Aminet 45 / Aminet 45 (2001)(GTI - Schatztruhe)[!][Oct 2001].iso / Aminet / game / role / ldmud-3.2-bin.lha / mud / doc / concepts / hooks < prev    next >
Text File  |  2001-07-26  |  18KB  |  441 lines

  1. CONCEPT
  2.         driver hooks
  3.  
  4. DESCRIPTION
  5.         To allow a greater flexibility of the muds, the gamedrivers
  6.         since 3.2.1 moved several once hardcoded 'underground'
  7.         activities from the driver into the mudlib. This includes for
  8.         example the differences between compat and native mode.
  9.  
  10.         The hooks are set with the privileged efun set_driver_hook().
  11.         Some of the hooks are mandatory, some not. Most hooks accept
  12.         unbound lambda closures as values, some also lfun closures or
  13.         even strings.
  14.         The hooks are identified by an ordinal number, for which
  15.         symbolic names are defined in /sys/driverhooks.h.
  16.  
  17.         H_MOVE_OBJECT0
  18.         H_MOVE_OBJECT1
  19.           Mandatory hooks to implement the efun void move_object().
  20.           Hook setting must be an unbound lambda closure:
  21.  
  22.             void <closure>(object item, object dest)
  23.  
  24.           Upon call, the hook has to perform the move itself (by using
  25.           efun308()) and all depending actions (like the calls to
  26.           init() to add actions).
  27.  
  28.           The difference lies in the binding of the set hook prior to
  29.           the call: the H_MOVE_OBJECT0 closure is bound to the current
  30.           object, the H_MOVE_OBJECT1 to 'item'.
  31.           If both hooks are set, H_MOVE_OBJECT0 is ignored.
  32.  
  33.  
  34.         H_LOAD_UIDS
  35.         H_CLONE_UIDS
  36.           Mandatory hooks to determine the uid and euid of loaded or cloned
  37.           objects.  Hook settings can be any closure:
  38.  
  39.             mixed <load_uids closure> (string objectname)
  40.             mixed <clone_uids closure>(object blueprint, string objectname)
  41.  
  42.           When an object is newly loaded, the H_LOAD_UIDS hook is
  43.           called with the object name as argument.
  44.           When an object is cloned, the H_CLONE_UIDS hook is called
  45.           with the blueprint object as first and the clone's designated
  46.           name as second argument.
  47.           In both cases the new object already exists, but has 0 uids.
  48.  
  49.           For the result, the following possibilities exist (<num> is
  50.           a non-zero number, <no-string> is anything but a string):
  51.  
  52.              "<uid>"                    -> uid = "<uid>", euid = "<uid>"
  53.              ({ "<uid>", "<euid>" })    -> uid = "<uid>", euid = "<euid>"
  54.              ({ "<uid>", <no-string> }) -> uid = "<uid>", euid = 0
  55.  
  56.           If strict-euids is not active, the following results are
  57.           possible, too:
  58.  
  59.              <num>                      -> uid = 0, euid = 0
  60.              ({ <num>, "<euid>" })      -> uid = 0, euid = "<euid>"
  61.              ({ <num>, <no-string> })   -> uid = 0, euid = 0
  62.  
  63.  
  64.         H_CREATE_SUPER
  65.         H_CREATE_OB
  66.         H_CREATE_CLONE
  67.           Optional hooks to initialize an object after creation.
  68.           Hook setting can be unbound lambda closures, or the name of
  69.           the function to call in the object.
  70.  
  71.           H_CREATE_SUPER is called for blueprints implicitely loaded
  72.           by inheritance, H_CREATE_OB for explicitely loaded
  73.           blueprints/objects, and H_CREATE_CLONE for cloned objects.
  74.  
  75.           If the hook is a closure expecting an argument, it is bound
  76.           to the current object and called as
  77.  
  78.             int <closure> (object obj_to_init)
  79.  
  80.           If the hook as a closure without arguments, it is bound to
  81.           the object to be initalized and called as
  82.  
  83.             int <closure> ( void )
  84.  
  85.           If the result of the call is a non-zero number, it is used
  86.           as the interval to wait before the first reset(), else the default
  87.           interval computed from TIME_TO_RESET is used.
  88.  
  89.           If the hook is defined as the name of an lfun in the object,
  90.           it is called in the object as
  91.  
  92.             void <name>(0)
  93.  
  94.           and any result is ignored.
  95.           In this call the previous_object() is the object initiating
  96.           the load.
  97.  
  98.  
  99.         H_RESET
  100.           Optional hook to reset an object.
  101.           Hook setting can be unbound lambda closures, or the name of
  102.           the function to call in the object.
  103.  
  104.           This hook is called to reset the object after a certain time
  105.           since its creation/last reset.
  106.  
  107.           If the hook is a closure, it is bound to the object to be
  108.           reset and called with no argument:
  109.  
  110.             void|int <closure> ( void )
  111.  
  112.           If the result of the call is a positive number, it is used
  113.           as the interval to wait before the next reset().
  114.           If the result is 0, the default interval computed from
  115.           TIME_TO_RESET is used.
  116.           If the result is a negative number, the object will not be
  117.           reset again, unless directed otherwise by set_next_reset().
  118.  
  119.           If the hook is defined as the name of an lfun in the object,
  120.           it is called in the object as
  121.  
  122.             void <name>(1)
  123.  
  124.           and any result is ignored.
  125.           In this call the previous_object() is the object initiating
  126.           the reset.
  127.           If the function does not exist, the object won't be reset
  128.           again.
  129.  
  130.  
  131.         H_CLEAN_UP
  132.           Optional hook to clean up an object.
  133.           Hook setting can be any closure, or the name of the function
  134.           to call in the object.
  135.  
  136.           This hook is called for an object if it hasn't been used
  137.           for at least TIME_TO_CLEAN_UP seconds, to give it the
  138.           opportunity to self destruct.
  139.  
  140.           If the hook is a closure, it is called as
  141.  
  142.             int <closure>(int ref, object ob)
  143.  
  144.           with the object to clean up as first, and its refcount as
  145.           second argument. Lambda closures are also bound to the
  146.           object prior to the call.
  147.  
  148.           If the hook is the name of an lfun, it is called in the
  149.           object with its refcount as argument:
  150.  
  151.             void|int <name>(int ref)
  152.  
  153.           In both calls, the refcount is constructed as:
  154.  
  155.             ref = 0: the object is a clone, or a blueprint with
  156.                      replaced program.
  157.             ref = 1: the object is a swapped or unused blueprint.
  158.             ref > 1: the object is a used blueprint with <ref> references.
  159.  
  160.           The cleanup method has the possibility to destruct the
  161.           object. To survive this time, but try again some time later,
  162.           the call has to result in a non-zero value.
  163.  
  164.           If the hook specifies a non-existing lfun, or if the call
  165.           returns 0, no further attempt to clean up this object will be done.
  166.  
  167.  
  168.         H_COMMAND
  169.           Optional hook to parse and execute commands. If this hook is used,
  170.           it bypasses the normal command parsing done by the driver (including
  171.           the MODIFY_COMMAND and NOTIFY_FAIL hooks).
  172.  
  173.           The hook is called with two parameters: the command received
  174.           from the living (interactive user or NPC), and the living object
  175.           (the 'command giver') itself. The hook has to return non-0 if the
  176.           command was found and executed, and 0 otherwise.
  177.  
  178.           At the time the hook is called, query_command() returns the command
  179.           string and this_player() returns the living object. query_verb() and
  180.           query_notify_fail() return 0.
  181.  
  182.           If the hook is a string, it is the name of an lfun in the command
  183.           giver:
  184.  
  185.               int <name>(string command, object command_giver)
  186.  
  187.           If the hook is a closure, it is called as:
  188.  
  189.               int <closure>(string command, object command_giver)
  190.  
  191.           Lambda-closures are additionally bound to the command_giver.
  192.  
  193.  
  194.         H_MODIFY_COMMAND
  195.           Optional hook to modify commands (both entered or given by a
  196.           call to command()) before the parser sees them (this includes
  197.           special commands like 'status').
  198.  
  199.           Hook setting can be any closure, the name of the function
  200.           to call in the object, or a mapping.
  201.  
  202.           For interactives this hook is used only if the interactive
  203.           object has no command modifier already set by the efun
  204.           set_modify_command().
  205.  
  206.           If the hook is a closure, it is called as
  207.  
  208.             int|string <closure>(string cmd, object player)
  209.  
  210.           with the entered command as first, and the command giving
  211.           player as second argument.
  212.  
  213.           If the hook is a string, it is used as the name of an lfun
  214.           in the command giving player, which is called as
  215.  
  216.             int|string <name>(string cmd)
  217.  
  218.           If the hook is a mapping, it is queried with the given
  219.           command as index, and the data retrieved is used (defaults
  220.           to 0 if no data is stored for a given command). If an entry
  221.           is a closure, it is called as
  222.  
  223.             int|string <closure>(string cmd, object player)
  224.  
  225.           and the result from the call is used as 'the' result.
  226.  
  227.           The result is treated equal in all three cases.
  228.           If the result is a string, it is the new command to execute
  229.           instead of the given one. Note that it is not possible to
  230.           make several commands from one this way!
  231.           If the result is a non-zero number, the given command is to
  232.           be ignored. In case of the closure/lfun setting this may
  233.           mean that the closure/lfun already executed it.
  234.           If the result is 0, the originally given command is to be
  235.           used (not available for closure settings).
  236.  
  237.           It is possible for the hook to change the command giver
  238.           (this_player()) for the execution of the command. This means that
  239.           even though the commands are execute for the original commandgiver,
  240.           this_player() will return the changed commandgiver.
  241.  
  242.  
  243.         H_MODIFY_COMMAND_FNAME
  244.           Mandatory hook specifying the name of the 'modify_command'
  245.           function to call for newly entered commands as result of a
  246.           set_modify_command().
  247.  
  248.           Hook setting must be a string.
  249.  
  250.           If set_modify_command() is used for an interactive user, all
  251.           newly entered commands are first passed to the function
  252.           named by this hook.
  253.  
  254.           It is possible for the hook to change the command giver
  255.           (this_player()) for the execution of the command. This means that
  256.           even though the commands are execute for the original commandgiver,
  257.           this_player() will return the changed commandgiver.
  258.  
  259.  
  260.         H_NOTIFY_FAIL
  261.           Mandatory hook to issue the default message if an entered
  262.           command couldn't be parsed and no notify_fail() command is
  263.           in effect.
  264.           Hook setting can be a any closure, or a string.
  265.  
  266.           If set to a string, it is the message returned to the
  267.           player.
  268.           If set to a closure, it is called as
  269.  
  270.             string <closure>(string entered_command, object cmd_giver)
  271.  
  272.           and the result is used as failure message. Lambda closures
  273.           are bound to this_player() prior to execution.
  274.  
  275.           <cmd_giver> is the object which received the command in
  276.           the first place. It is usually identical with this_player(),
  277.           unless the H_MODIFY_COMMAND hook changed it.
  278.  
  279.  
  280.         H_SEND_NOTIFY_FAIL
  281.           Optional hook to send the notify fail message, regardless
  282.           of how it was determined, to the player. If the hook is not
  283.           set, the message is delivered using tell_object() internally.
  284.           Hook setting can be a string or a closure.
  285.  
  286.           If the hook is a string, it is the name of a (possibly static)
  287.           function to call in the current command giver. If the hook
  288.           is a closure, it is the function to be called. Lambda closures
  289.           are bound to the current command giver first.
  290.  
  291.           The function is called as
  292.  
  293.             void <function>(string msg, object msgobj, object orig_cmd_giver)
  294.  
  295.           <msg> is the notify fail message to be delivered.
  296.           <msgobj> is the object which set the message. It is 0 for the
  297.           default message.
  298.           <orig_cmd_giver> is the object for which the original command
  299.           was first received. It is usually identical with the current
  300.           command giver this_player().
  301.  
  302.  
  303.         H_NO_IPC_SLOT
  304.           Optional hook specifying the message given to logins
  305.           rejected due to space limitations (MAX_PLAYER).
  306.           Hook setting has to be string.
  307.           If set to 0, the default message "Lpmud is full. Come back
  308.           later." is issued.
  309.  
  310.  
  311.         H_INCLUDE_DIRS
  312.           Semi-mandatory hook specifying the directories where <>-type
  313.           include files are searched (this includes ""-includes not
  314.           found as specified).
  315.           Hook setting may be any closure or a string array.
  316.           If not set, only ""-type includes may be used in LPC
  317.           programs.
  318.  
  319.           If the hook setting is a string array, it has to contain the
  320.           path names of those directories where <>-type includes are
  321.           to be searched. The directories are searched in the order
  322.           they appear in the array. The directory name and the name of
  323.           the actual include file are concatenated, therefore the
  324.           directory names have to end in '/'. Leading slashes may be
  325.           omitted.
  326.  
  327.           If the setting is a closure, it is called as
  328.  
  329.             string <closure>(string include_name, string current_file)
  330.  
  331.           with the name of the desired include file as first, and the
  332.           name of the compiled LPC file as second argument.
  333.           Result has to be the complete path name of the include file
  334.           to use (leading slashes may be omitted).
  335.           If the closure is a lambda closure, it is bound to
  336.           this_object() prior to execution.
  337.  
  338.           See also: master apply include_file()
  339.  
  340.  
  341.         H_TELNET_NEG
  342.           Optional hook to specifiy how to perform a single telnet
  343.           negotiation.
  344.           Hook setting may be any closure or a string.
  345.           If not set, most telnet options are rejected (read: only a
  346.           very minimal negotiation takes place).
  347.  
  348.           The hook is called whenever the driver receives a demand for
  349.           option negotiation upon NAWS (window size) and TELOPT_TTYPE
  350.           (terminal type). The hook has then to perform the
  351.           negotiation using the efun binary_message().
  352.  
  353.           Alternatively, if H_NOECHO is set, this hook is called
  354.           for all telnet data received.
  355.  
  356.           If the setting is a string, it used as name of an lfun to
  357.           call in this_player():
  358.  
  359.             void|mixed <name>(int action, int option [, int * opts ] )
  360.  
  361.           Similar, if the setting is a closure, it is called as:
  362.  
  363.             void|mixed <closure>(int action, int option [, int * opts ] )
  364.  
  365.           with unbound lambda-closures being bound to this_player()
  366.           prior to execution.
  367.  
  368.           The hook is called for a 'DO/DONT/WILL/WONT <opt>' with the action
  369.           (DO/DONT/...) as the first, and <opt> as the second argument.
  370.  
  371.           If the driver receives the sequence
  372.  
  373.             IAC SB <opt> <opts>...
  374.           
  375.           followed by IAC SB/SE,  the hook is called with 'SB' as first
  376.           argument, <opt> as second, and <opts> as an array of integers as
  377.           third argument.
  378.  
  379.  
  380.         H_NOECHO
  381.           Optional hook to specifiy how to perform the telnet actions
  382.           to switch the echo mode (used for e.g. password input_to()s).
  383.           Hook setting may be any closure or a string.
  384.           If not set, a default handling is performed.
  385.  
  386.           If the setting is a string, it used as name of an lfun to
  387.           call in the intercative <user>:
  388.  
  389.             void <name>(int flag, object user)
  390.  
  391.           where <flag> is the echo-flag passed to the input_to()
  392.           statement.
  393.           Similar, if the setting is a closure, it is called as:
  394.  
  395.             void <closure>(int flag, object user)
  396.  
  397.           with unbound lambda-closures being bound to this_player()
  398.           prior to execution.
  399.  
  400.           When set, the hook is called whenever the driver needs to
  401.           change the echo mode, thus you can negotiate about things
  402.           that are coupled with it, like LINEMODE or
  403.           character-at-a-time.
  404.           
  405.           IMPORTANT: If this hook is used, the control of all telnet
  406.           negotiation is transferred to the mudlib (you must combine it
  407.           with H_TELNET_NEG to conform to the telnet protocol).
  408.  
  409.  
  410.         H_ERQ_STOP
  411.           Optional hook to notify the mudlib about the termination of
  412.           the erq demon.
  413.           Hook setting may be any closure.
  414.  
  415.           The closure is called without arguments:
  416.  
  417.             void <closure>()
  418.  
  419.           and may do whatever it likes to clean-up after the erq.
  420.  
  421.  
  422. HISTORY
  423.         H_NOTIFY_FAIL recevied the new 'command_giver' argument in 3.2.7.
  424.         The hooks concept was introduced in 3.2.1
  425.         The hook for moving was introduced in 3.2.1@1
  426.         The hook for clean up was introduced in 3.2.1@34
  427.         The hook for modifying commands was introduced in 3.2.1@51,
  428.             the evaluation of mapping as hooks was extended in 3.2.1@54.
  429.             The lfun called as result of set_modify_command() was
  430.             'hooked' in 3.2.1@109.
  431.         The hooks for notify_fail and full muds were introduced in 3.2.1@55.
  432.         The hook for include dirs was introduced in 3.2.1@57.
  433.         The hook for telnet negotiation was introduced in 3.2.1@60.
  434.         The hooks for no-echo negotiation and erq-lossage notification
  435.             were introduced in 3.2.1@85.
  436.         H_COMMAND was introduced in 3.2.7.
  437.         H_SEND_NOTIFY_FAIL was introduced in 3.2.9.
  438.  
  439. SEE ALSO
  440.         native(C), set_driver_hook(E)
  441.